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APPEAL BRIEF UNDER 37 C.F.R. § 1.192 



This brief is in support of Appellant's appeal from the final rejection of 
claims 1-49 dated July 19, 2002. A Notice of Appeal was filed on November 15, 2002. 



A. REAL PARTY IN INTEREST 

The present application has been assigned to MICROSOFT 
CORPORATION. The inventors assigned their respective interests in the present 
application to LIQUID AUDIO, INC. by an assignment recorded April 9, 1999 at reel 
9892, frame 0951. Subsequently, LIQUID AUDIO, INC. assigned its interest in this 
application to MICROSOFT CORPORATION by an assignment dated September 27, 
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2002. The September 27, 2002 assignment was forwarded to the Patent and Trademark 
Office for recordation on December 16, 2002; acknowledgment of this recordation has 
not yet been received. 

B. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences. 

C. STATUS OF CLAIMS 

1. Claims 1-49 are pending, of which claims 1 and 39 are independent. 
Claims 1-49 are reproduced in Appendix A, attached hereto. Claims 1-5 and 9-49 stand 
rejected. Claims 1-3, 10-26, and 39-49 have been rejected under 35 U.S.C. § 102(e), as 
being anticipated by U.S. Patent No. 5,715,314 to Payne, et al. (hereinafter "Payne"). 
Claims 4, 5, and 9 have been rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Payne in view of U.S. Patent No. 6,236,971 to Stefik, et al. (hereinafter "Stefik"). 
Claims 27-38 have been rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Payne. Claims 6-8 have been found to be allowable, as discussed below in section D. 

D. STATUS OF AMENDMENTS 

An after-final amendment to claim 6 was filed in response to the Final 
Rejection, and the Examiner indicated that this amendment would be entered for the 
purpose of this appeal. 

In the Final Rejection dated July 19, 2002, claims 6-8 had been rejected 
under 35 U.S.C. § 1 12, second paragraph. In response to the Final Rejection, applicant 
filed an amendment under 37 C.F.R. § 1.1 16 amending claim 6. In a December 17, 2002 
Advisory Action, the Examiner found that the after-final amendment had overcome the 
rejection of claims 6-8, and agreed to enter the amendment for the purpose of this appeal. 
Thus, the amendment to claim 6 will be treated as having been entered, and the 
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reproduction of the pending claims at Appendix A reflects this amendment. Moreover, 
since the rejection of dependent claims 6-8 has been overcome, appellants will consider 
these dependent claims as being allowable if rewritten in independent form. 

E. SUMMARY OF THE INVENTION 

The present invention relates to the distribution of digital products, such as 
music, videos, etc., over wide-area networks. The invention makes use of various 
components that communicate with each other over a wide-area network, and that 
cooperate with each other to effectuate the distribution of digital products. 1 

In order to purchase and receive a digital product in accordance with the 

invention, a purchaser uses his/her computer (the "client computer") to contact a 

"merchant computer." The merchant computer receives and processes requests to 

purchase digital products. 2 After the purchaser has transmitted a payment authorization to 

the merchant computer, the merchant computer transmits a "content reservation request" 

to a content manager computer. 3 The content reservation request contains data that 

specifies which product the purchaser has purchased. 4 If the specified product is present 

in the content manager's database, then the content manager creates a "voucher packet." 

The voucher packet contains a "receipt token," which is later presented to a "delivery 

server" in order to allow delivery of the product to the purchaser. 5 

Thus, the user initially engages in a purchase transaction with the 

merchant computer; the merchant computer informs the content manager computer that 

the user has paid for a particular product; and the content manager creates a receipt token 

that ultimately directs a delivery server to provide the user with the product that the user 

has paid for. 



1 Application, p. 5. 

2 Application, p. 6. 

3 Application, p. 32. 
4 Id. 

5 Application, p. 33. 
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The independent claims of the present application (1 and 39) recite 
methods of conducting electronic commerce, including the above-described interaction 
between the merchant computer and the content manager. In particular, claim 1 recites 
that a "merchant computer system" receives a request to purchase a digital product and 
also receives payment data, and that a "content manager computer system" then receives 
a request from the merchant computer system that the purchased product be delivered to a 
client. Claim 39 recites that the merchant computer system receives a request to purchase 
a digital product (and also receives payment data), and that a request for a "reservation" 
of the product is sent to a content manager computer system. 

F. ISSUE ON APPEAL 

Whether claims 1-5 and 9-49 patentably define over Payne and/or over 
Payne in view of Stefik. 

G. GROUPING OF CLAIMS 

For the purpose of this appeal, the following groups of claims stand or fall 

together: 

Group I: Claims 1-5, 10-12, 14-22, and 24-38; 

Group II: Claims 39-41 and 43-49; 

Group III: Claim 9 

Group IV: Claims 13 and 42 

Group V: Claim 23. 

H. ARGUMENT 

In the Office Action dated July 19, 2002, the Examiner finally rejected 
independent claims 1 and 39 as being anticipated by Payne under 35 U.S.C. §§ 102(e). 
Thus, appellants initially focus their argument on why claims 1 and 39 are not anticipated 
by Payne, and will then turn to a discussion of certain dependent claims. 
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Independent claim 1 is not anticipated by Payne 

Independent claim 1 is directed to a "method for conducting electronic 
commerce through a computer network." In claim 1, both a "merchant computer system" 
and a "content manager computer system" participate in the claimed method. In 
particular, claim 1 recites the following steps: 

receiving, in a merchant computer system . . . , a 
purchase request for a digital product; 

receiving payment data in the merchant computer 
system wherein the payment data specifies remuneration 
for the digital product; 



receiving, in the content manager computer system, 
a delivery request signal from the merchant computer 
system wherein the delivery request signal requests 
delivery of the digital product to a client computer system 

In other words, claim 1 calls for a "merchant computer system" to do both of the 
following: 

• Receive a purchase request for a digital product; and 

• Send to the content manager computer system a request that the 
digital product be delivered to a client 

This structure is substantially different from Payne. While Payne uses separate computer 
systems to receive purchase requests (Payne's "payment computer") and to cause the 
purchased item to be delivered (Payne's "merchant computer") 6 , in Payne the "merchant 
computer" does not receive instructions from the "payment computer," but rather receives 
its instructions from the buyer. Payne is devoid of any teaching that a first computer 



6 Unfortunately, the present application and Payne each use the term "merchant" in different ways, 
which may cause some confusion. In the present application, the "merchant computer system" receives 
payment for a digital product, while in Payne, the "merchant computer" fulfills the buyer's order after 
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system that receives a purchase request and payment, and a second computer system that 

requests delivery to the buyer, can communicate with each other directly. 

Payne teaches that a buyer engages in a transaction to purchase a product 

(such as "information products" or "hard goods") 7 by interacting with both a "payment 

computer" and a "merchant computer." The buyer transmits payment to the payment 

computer, 8 and then receives, from the payment computer, a Uniform Resource Locator 

(URL) representing the fact that the buyer has paid for an item. 9 Payne calls this URL the 

"access" URL. 10 This "access" URL is then instantiated as a link on the buyer's 

computer, and the buyer's computer follows the link by generating a Hypertext Transfer 

Protocol (HTTP) request based on the URL and transmitting this request to the merchant 

computer. 11 The merchant computer then verifies the information contained in the request 

based on the URL, and uses this information either to provide a "fulfillment document" 

representing the buyer's purchase, or to provide the buyer with a document stating that 

access to the purchased product is not allowed. 12 

Thus, there is a crucial distinction between claim 1 and Payne: In claim 1, 

the request to deliver a product is sent from computer that receives payment (the 

"merchant computer system") to the computer that causes the purchase to be fulfilled (the 

"content manager computer system"). In Payne, no such direct communication takes 

place. 

The fact that claim 1 calls for the merchant computer system to 
communicate directly with the content manager is significant because it provides a 
measure of security that cannot be realized by the system of Payne: In Payne the buyer is 
responsible for transmitting to the merchant computer the very data (in the form of an 

payment has been transmitted to the "payment computer." Thus, the "merchant computer system" of the 
present application receives the buyer's payment, whereas the "merchant computer" of Payne does not. 

7 Payne, col. 4, 11. 56-60. 

8 Payne, col. 5, 11. 27-47. 

9 Payne, col. 7, 11. 18-30. 

10 Payne, col. 7, 11. 31-32 & FIG. 2G, element 90. 

" See Payne, FIG. 2H, element 92; col. 9, 11. 51-61. 
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HTTP request based on the "access" URL) that informs the merchant computer that the 
buyer has paid for a valuable product. The HTTP request contains information such as: 
which product the buyer is entitled to receive, how long the buyer is entitled to use the 
product for, and the network address identifier of the buyer's computer. 13 Since the buyer 
handles the URL on which the HTTP request is based, there is a possibility that the buyer 
will tamper with this data, thereby allowing the buyer to receive products he has not paid 
for, or that the buyer will extend the time that he is entitled to use the product, or that the 
buyer will attempt to grant access to the product to a different buyer who has not paid for 
the product. No such tampering is possible in the method of claim 1, because the 
merchant computer sends the delivery request directly to the content manager computer, 
without involving the buyer at all. 14 



that teaches that a single system both: (1) receives a purchaser's payment for a product, 
and (2) sends a request to another system directing that the purchaser receive the product. 
Instead, the Examiner has cited two separate computers in Payne that allegedly perform 
the function of the claimed "merchant computer system." As described in appellants' 
response to the final rejection, the Examiner has found that: 



• When the claimed "merchant computer system" is receiving a 
purchase request from the buyer, the merchant computer system is 
Payne's "payment computer"; and 

• When the claimed "merchant computer system" is sending a 
request to the content manager computer system, the merchant 



12 Payne, col. 7, 11. 36-54. 

13 Payne, col. 7, 11. 18-23. 

14 It should be noted that, in the present invention, a digital product is delivered to the purchaser 
from a delivery server, and the user may handle the data that instructs the delivery server to deliver this 
product. However, even if the delivery server were analogous to Payne's merchant computer - and the 
Examiner has not asserted that any such analogy exists - the threshold issue on this appeal is whether the 
claimed "content manager computer system" reads on Payne's merchant computer (or any other structure 
described in Payne). As appellants have argued herein, the content manager computer system does not read 
on Payne's merchant computer system, because Payne's merchant computer system does not communicate 
directly with the payment computer that receive a purchase request and payment. 



In the Final Rejection, the Examiner has not cited any portion of Payne 
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computer system is Payne's "buyer's computer. 



Thus, the Examiner combined two different computers in Payne to accomplish what a 
single computer does in claim 1. As discussed above, the distinction of two computers 
versus one is significant and has implications for the security of the underlying system. 



Rejection, pointed out that the Examiner had combined two separate structures in Payne 
(the "payment computer" and the "buyer's computer") to do what claim 1 accomplishes 
with a single "merchant computer system,", the Examiner responded by stating that he 
was not actually reading any function of the claimed "merchant computer system" onto 
both Payne's "payment computer" and "buyer's computer." Rather, the Examiner asserts, 
the rejection reads the claimed "merchant computer system" onto only Payne's "payment 
computer," and, while Payne appears to teach that a URL is sent from the buyer's 
computer to the merchant computer, Payne is actually sending the URL from the payment 
computer to the merchant computer via the buyer's computer. In the Examiner's words: 



Payne et al. teach a step of sending an access URL . . . from 
the payment computer 14 ... to the buyer computer 12 
which, in turn, sends it to the merchant computer 14 . . .. 
There are no steps recited in the claims that require the 
delivery request signal to be sent directly to the content 
manager computer from the merchant computer without 
passing through any intervening computers. 16 



Essentially, the Examiner characterizes Payne's buyer's computer as a mere conduit 
through which the payment computer sends a URL to the merchant computer. This 
characterization of Payne is wrong, and represents a misunderstanding of the process 
described in Payne. Payne's buyer's computer is not a mere conduit in the sending of data 
from one place to another; the buyer's computer participates in the creation of data, and 
sends to the merchant computer data that is different from that which it receives from the 



When appellants, in the November 25, 2002 response to the Final 



15 See 1 1/25/02 Amendment, p. 4. 

16 See Advisory Action, p. 2. 
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merchant computer. 

According to Payne, the concept of "sending" a URL means two different 
things depending upon whether the URL is specified as a "redirection." This fact is 
significant, because in Payne the "access" URL is sent from the payment computer to the 
buyer's computer as a redirection, but from the buyer's computer to the merchant 
computer as a non-redirection. Thus, Payne's buyer's computer does not merely pass 
along data between the payment computer and the merchant computer. Instead, the 
buyer's computer receives data (the access URL) from the payment computer, processes 
that data in some way, and then sends different data to the merchant computer. Since the 
merchant computer does not receive the same data that the payment computer sent to the 
buyer's computer, the Examiner's characterization of the buyer's computer as a mere 
"intervening" computer in the sending of data from one computer to another is simply 
wrong. 

Payne explains the "sending" of URLs as follows: 

Whenever the present application states that one 
computer sends a URL to another computer, it should be 
understood that in preferred embodiments the URL is sent 
in a standard HTTP request message, unless a URL 
message is specified as a redirection in the present 
application. . . . The term "URL" as used in the present 
application is an example of a "link," which is a pointer to 
another document or form . . . , 17 

In other words, "sending" a URL has a different meaning depending upon whether the 
sending is a redirection. The "access" URL is clearly a "redirection," since Payne states 
that the "payment computer sends redirect to access URL to buyer's computer." 18 Thus, 
when Payne's "access" URL is sent to from the payment computer to the buyer's 
computer, the URL becomes a link on the buyer's computer. When that link is followed, 
the buyer's computer generates an HTTP request message based on the URL, and it is 

17 Payne, col. 9, 11. 51-61 (emphasis added). 

18 Payne, FIG. 2G (emphasis added); see also, col. 7, 1. 31. 



MSFT-1701/303314.1 - 10 - PATENT 



this HTTP request message - not the original access URL - that is sent to the merchant 
computer. 

Thus, contrary to the Examiner's reasoning, Payne does not teach that the 

buyer's computer merely carries the "access" URL en route from the payment computer 

to the merchant computer. Instead, the buyer's computer receives one thing from the 

payment computer (a URL) and then sends another thing (an HTTP request message) to 

the merchant computer. The buyer's computer - by generating the HTTP request message 

based on the URL - is an active participant in the process described by Payne, not a mere 

"intervening computer." The Examiner's argument on claim 1 is wholly based on the idea 

that the buyer's computer is simply passing along something from the payment computer 

to the merchant computer. This reasoning is simply wrong. Since the Examiner's 

argument on claim 1 is based on a misapprehension as to what the buyer's computer in 

Payne is sending to the merchant computer, the rejection of claim 1 as being anticipated 

by Payne cannot stand. 

Accordingly, appellants respectfully submit that claim 1 is patentable over 

Payne, and that dependent claims 2-38 are patentable at least by reason of their direct or 

indirect dependency on claim 1. Thus, appellants request that the rejection of claims 1-5 

and 9-38 be reversed. (Claims 1-5 and 9-38 include all of the Group I claims, and also 

includes certain claims in Groups III, IV, and V. For reasons discussed below, there are 

additional reasons why the rejection of the Group III, IV, and V claims should be 

reversed.) 

Independent claim 39 is not anticipated by Payne 

Independent claim 39 is directed to a method for conducting electronic 

commerce through a computer network, and calls for: 

receiving, in a merchant computer system of the 
computer network, a purchase request for the digital 
product; 
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receiving payment data in the merchant computer 
system wherein the payment data specifies remuneration 
for the digital product; 

sending a request for reservation of the digital 
product to a content manager computer system . . . which is 
coupled to the merchant computer system through the 
computer network; .... 

In other words, claim 39 calls for both a merchant computer system and a content 
manager computer system. A request to purchase a digital product, and payment for that 
product, are sent to the merchant computer system, and a request for "reservation" of the 
digital product is sent to a content manager computer system. Notably, the content 
manager computer system is coupled to the merchant computer system through a 

computer network. 

The Examiner rejected claim 39 as being anticipated by Payne. As with 
claim 1, the Examiner reads the claimed "merchant computer system" onto Payne's 
"payment computer," and reads the claimed "content manager computer system" onto 
Payne's merchant computer. However, as discussed above, the relationship between 
Payne's payment computer and merchant computer on the one hand, and the relationship 
between the claimed merchant computer system and content manager computer system 

on the other hand, are different. 

At a minimum, Payne contains no teaching that the payment computer is 

connected through a network to the merchant computer. As discussed above, Payne's 

payment computer and merchant computer communicate by the payment computer 

sending a URL to the buyer's computer, which then generates an HTTP message based 

on the URL. There is no teaching in Payne that the payment and merchant computers 

communicate directly, or that they are otherwise connected to each other through a 

computer network. In fact, it is clear from the teachings of Payne - as described above in 

connection with claim 1 - that the payment computer and merchant computer 

communicate only indirectly through the buyer's computer, and require action by the 
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buyer's computer in order to effectuate such communication. 

Since claim 39 requires that the merchant computer system and the content 
manager computer system be "coupled" to each other "through a computer network," it 
claim 39 recites at least one feature that is not taught by Payne. Thus, the rejection of 
claim 39 on the ground of anticipation must be reversed. Additionally, since claims 40-49 
are either directly or indirectly dependent on claim 39, the rejections of these claims must 

be reversed as well. 

Thus, appellants respectfully request that the rejection of claims 39-49 be 
reversed. (Claims 39-49 include all of the Group II claims, and also include one claim in 
IV; as discussed below, there are additional and cumulative reasons why the Group IV 
claim should be reversed.) 

Claim 9 

Claim 9 is dependent on claim 1, and recites the steps of "encrypting the 

digital product with [a] new encryption key" and "discarding the new encryption key." 

The Examiner found that claim 9 was obvious over Payne in view of Stefik (see Final 

Rejection, f 42). However, neither Payne nor Stefik teaches the discarding of an 

encryption key. The Examiner merely makes general reference to the "encryption 

element" of Stefik, and does not explain how Stefik (or Payne) teaches the discarding of 

an encryption key. Appellants submit that there is no such teaching or suggestion in 

Stefik (or Payne). 

As noted above, claim 9 (the Group III claim) is patentable at least by 

reason of its dependency on claim 1. However, the foregoing provides and independent 

and cumulative reason why claim 9 is patentable over Payne and Stefik. Thus, the section 

103(a) rejection of claim 9 should be reversed. 



Claims 13 and 42 

Claim 13 is dependent on claim 1. The Examiner found that claim 13 was 
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anticipated by Payne (see Final Rejection, 13). Claim 13 recites that the merchant 
computer system sends data to a "payment authority" and receives payment authorization 
information from the "payment authority." The Examiner reads these features onto col. 1, 
11. 55-64 of Payne. The cited portion of Payne contains no such teaching. 

As described above, the participants in the Payne system are the payment 
computer, the merchant computer, and the buyer's computer. It is not clear how the 
Examiner derives this additional party - a "payment authority" - from the cited portion of 
Payne, or from any other portion of Payne. Appellants respectfully submit that Payne 
contains no such teaching. 

As noted above, claim 13 is patentable at least by reason of its dependency 
on claim 1 . However, the foregoing provides and independent and cumulative reason why 
claim 13 is patentable over Payne. Additionally, claim 42 is indirectly dependent on 
claim 39, and recites a language identical to that of claim 13. For the reasons stated 
above, the feature represented by this language is not taught in Payne. Accordingly, the 
section 102(e) rejection of claims 13 and 42 (the Group IV claims) should be reversed. 

Claim 23 

Claim 23 is dependent on claim 22, which, in turn, is dependent on claim 
1. Claim 22 recites, inter alia, that the "merchant computer system . . . communicates the 
delivery request signal to the content manager computer system." As discussed above in 
connection with claim 1, the Examiner has analogized Payne's "payment computer" and 
"merchant computer" to the claimed "merchant computer system" and "content manager 
computer system," respectively. As further discussed in connection with claim 1, Payne 
does not teach that the payment computer communicates with the merchant computer. 
Thus, the Examiner's finding that Payne anticipates claim 23 is incorrect. 

As noted above, claim 23 is patentable at least by reason of its (indirect) 

dependency on claim 1. However, the foregoing provides and independent and 
cumulative reason why claim 23 is patentable over Payne. Thus, the section 102(e) 
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rejection of claim 23 (the Group V claim) should be reversed. 



Conclusion 



For all the foregoing reasons, appellants respectfully request that the 



Board reverse the rejection of claims 1-5 and 9-49, and that this application be returned to 
the Examiner for allowance. As noted above, claims 6-8 have apparently been found 
allowable subsequent to the filing of the Notice of Appeal, and thus, upon return to the 
Examiner, those claims should be allowed as well. 



WOODCOCK WASHBURN LLP 
One Liberty Place - 46 th Floor 
Philadelphia, PA 19103 
Tel: (215) 568-3100 
Fax: (215) 568-3439 



Respectfully submitted, 



Peter M. Ullman 
Registration No. 43,963 
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APPENDIXA 
Claims on Appeal 

1. A method for conducting electronic commerce through a computer 
network, the method comprising: 

receiving, in a merchant computer system of the computer 
network, a purchase request for a digital product; 

receiving payment data in the merchant computer system wherein 
the payment data specifies remuneration for the digital product; 

sending a request for reservation of the digital product to a content 
manager computer system which can be different from the merchant computer system 
and which is coupled to the merchant computer system through the computer network; 

receiving, in the content manager computer system, a delivery 
request signal from the merchant computer system wherein the delivery request signal 
requests delivery of the digital product to a client computer system through the computer 
network; 

sending transaction identification data to the client computer 
system wherein the transaction identification data identifies the digital product and 
represents remuneration in accordance with the payment data; 

receiving, in a delivery computer system of the computer network, 
the transaction identification data from the client computer system; 

determining within the delivery computer system, in accordance 
with the transaction identification data, the digital product; and 

sending, from the delivery computer system, the digital product to 
the client computer system. 

2. The method of Claim 1 further comprising: 

sending, from the delivery computer system to the content manager 
computer system, a signal indicating that sending the digital product to the client 
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computer system is completed. 

3. The method of Claim 2 further comprising: 

recording, by the content manager computer system, purchase data 
identifying the digital product and indicating that the digital product was purchased. 

4. The method of Claim 3 further comprising: 

sending, by the content manager computer system, the purchase 
data to a media licensing computer system such that the media licensing computer system 
can apportion compensation for sales of the digital product. 



system and other purchase data from one or more other content manager computer 
systems to form aggregated purchase data; and 



system such that the rights agent computer system can apportion compensation for sales 
of the digital product. 

6. The method of Claim 5 wherein recording the purchase data comprises: 

encrypting the purchase data in such a manner that data held secret 
by the media licensing computer system is required for decrypting the purchase data. 

7. The method of Claim 6 wherein encrypting the purchase data is 
performed in such a manner that modification of the purchase data subsequent to the 
encrypting can be detected. 



5. The method of Claim 4 further comprising: 

aggregating purchase data from the content manager computer 



sending the aggregated purchase data to a rights agent computer 



8. The method of Claim 6 wherein encrypting the purchase data is 
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performed in such a manner that removal of the purchase data from a sequence of 
purchase data records subsequent to the encrypting can be detected. 

9. The method of Claim 1 wherein sending the digital product from the 
delivery computer system to the client computer system comprises: 

creating a new encrypting key which is intended to be used only 

once; 

encrypting the digital product with the new encryption key to form 
an encrypted digital product; 

sending the encrypted digital product to the client computer 

system; 

decrypting the encrypted digital product within the client computer 
system to recover the digital product; and 

discarding the new encryption key. 

10. The method of Claim 1 wherein requesting reservation by the 
merchant computer system comprises: 

encrypting data representing a requested reservation; 

sending the data as encrypted to the content manager computer 

system; and 

decrypting the data within the content manager computer system. 

11. The method of Claim 1 wherein, in response to requesting reservation 
by the merchant computer system, the content manager computer system effects such a 
reservation of the digital product by: 

forming transaction data which include (i) the transaction 
identification data, (ii) product identification data which identifies the digital product, and 
(iii) binding data which binds the transaction to the client computer system; and 
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sending the transaction data to the merchant computer system. 



12. The method of Claim 1 1 wherein sending the transaction identification 
data comprises encrypting the transaction identification data. 

13. The method of Claim 1 further comprising: 

sending, from the merchant computer system, the payment data to 
a payment authority; and 

receiving, in the merchant computer system from the payment 
authority, payment authorization data. 

14. The method of Claim 13 further comprising: 

sending the payment authorization data to the content manager 

computer system. 



16. The method of Claim 14 further comprising: 

recording, by the content manager computer system, that payment 
for the digital product has been authorized. 

17. The method of Claim 16 further comprising: 

receiving, in the merchant computer system from the content 
manager computer system, acknowledgment data which indicates that payment for the 
digital product has been recorded. 



15. The method of Claim 14 wherein sending the payment authorization 



data comprises: 



encrypting the payment authorization data. 
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18. The method of Claim 17 wherein the acknowledgment data includes 
the transaction identification data and a payment authorization token which identifies 
payment authorization as recorded by the content manager computer system. 

19. The method of Claim 18 wherein the delivery request signal includes 
the transaction identification data and the delivery authorization token. 

20. The method of Claim 19 wherein the delivery request signal is 
generated in response to selection of a URL by the user wherein the URL specifies the 
transaction identification data and the delivery authorization token. 

21. The method of Claim 17 wherein the acknowledgment data is 

encrypted. 

22. The method of Claim 1 wherein the delivery request signal is received 
in the content manager computer system from the client computer system; and 

further wherein the delivery request signal is generated by the 
client computer system in response to user-generated control signals. 

23. The method of Claim 22 wherein the user-generated control signals are 
incident to a graphical user interface of a web browser; and 

further wherein the user-generated control signals cause the client 
computer system to send the delivery request signal to the merchant computer system 
which in turn communicates the delivery request signal to the content manager computer 
system. 

24. The method of Claim 1 wherein the delivery request signal includes 
the transaction identification data. 
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25. The method of Claim 24 wherein the delivery request signal is 
generated in response to selection of a URL by the user wherein the URL specifies the 
transaction identification data. 

26. The method of Claim 1 wherein the transaction identification data, as 
received by the delivery computer system is certified as originating from the client 
computer system. 

27. The method of Claim 26 wherein the transaction identification data is 
certified by signing of the transaction identification data using asymmetric-key 
encryption. 



28. The method of Claim 1 wherein the digital product includes a digitized 

audio signal. 

29. The method of Claim 28 wherein the digital product includes a 
selection of one or more musical pieces. 

30. The method of Claim 29 wherein the digital product further includes 
textual data representing lyrics of the one or more musical pieces. 

31. The method of Claim 29 wherein the digital product further include 
textual data representing liner notes of the one or more musical pieces. 



32. The method of Claim 29 wherein the digital product further include 
textual data representing artist credits of the one or more musical pieces. 
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33. The method of Claim 29 wherein the digital product further include 
textual data representing critical commentary of the one or more musical pieces. 

34. The method of Claim 29 wherein the digital product further includes 
one or more graphical images of album artwork to accompany the one or more musical 
pieces. 

35. The method of Claim 29 wherein the digital product further includes 
one or more graphical images of advertisement artwork to accompany the one or more 
musical pieces. 

36. The method of Claim 35 wherein the advertisement artwork is selected 
specifically for the client computer system. 

37. The method of Claim 36 wherein the advertisement artwork is selected 
specifically for the client computer system in accordance with information of the user of 
the client computer system. 

38. The method of Claim 37 wherein the information of the user is 

demographic. 

39. A method for conducting electronic commerce through a computer 
network, the method comprising: 

receiving, in a merchant computer system of the computer 
network, a purchase request for a digital product; 

receiving payment data in the merchant computer system wherein 
the payment data specifies remuneration for the digital product; 
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sending a request for reservation of the digital product to a content 
manager computer system which can be different from the merchant computer system 
and which is coupled to the merchant computer system through the computer network; 

receiving, from the content manager computer system, voucher 
data which is readable by the content manager computer system and which represents to 
the content manager computer system a transaction in which the remuneration specified 
by the payment data is exchanged for the digital product. 

40. The method of Claim 39 further comprising: 

receiving, from the content manager computer system, inventory 
data which specifies available digital products, including the digital product, and 
specified remuneration to the content manager computer system for each of the available 
digital products. 

41. The method of Claim 40 wherein requesting reservation comprises: 

encrypting data representing a requested reservation; 

sending the data as encrypted to the content manager computer 

system; and 

decrypting the data within the content manager computer system. 

42. The method of Claim 40 further comprising: 

sending, from the merchant computer system, the payment data to 
a payment authority; and 

receiving, in the merchant computer system from the payment 
authority, payment authorization data. 

43. The method of Claim 42 further comprising: 

sending the payment authorization data to the content manager 



# 
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computer system. 



44. The method of Claim 43 wherein sending the payment authorization 



data comprises: 



encrypting the payment authorization data. 



45. The method of Claim 44 further comprising: 

receiving, in the merchant computer system from the content 
manager computer system, acknowledgment data which indicates that payment for the 



46. The method of Claim 45 wherein the acknowledgment data includes 
the transaction identification data and a payment authorization token which identifies 
payment authorization as recorded by the content manager computer system. 

47. The method of Claim 46 wherein the delivery request signal includes 
the transaction identification data and the payment authorization token. 

48. The method of Claim 47 wherein the delivery request signal is 
generated in response to selection of a URL by the user wherein the URL specifies the 
transaction identification data and the payment authorization token. 

49. The method of Claim 45 wherein the acknowledgment data is 

encrypted. 



digital product has been recorded. 



